feat(content-serve): delegate with token caveat #1603
Conversation
fforbeck
changed the title
fforbeck
force-pushed
the
feat/content-serve-auth-token
branch
from
ca9ab26 to
e804824
Compare
fforbeck
force-pushed
the
feat/content-serve-auth-token
branch
from
e804824 to
3f76be3
Compare
There was a problem hiding this comment.
I'm not sure it's a good idea to set the token on the wildcard capability.
What if a space/content/serve/* delegation is required for the gateway to serve data and record egress at all. That means that it is up to the service to decide the terms for rate limiting, which may be extremely restrictive eventually.
If you (the user) wants to lift those restrictions or manage your own restrictons you'd also delegate a more specific non-wildcard capability (space/content/serve/http) with a token (and eventually other optional restrictions, like CID, or IP address or referer for example).
I think this is preferable, because the user will want to create and revoke multiple access tokens, without removing the ability for the gateway to serve data / record egress in general.
You'd then perhaps manage tokens in the client like:
interface Client {
// ... existing methods
// Calls `access/delegate` with `space/content/serve/http`, allowing access with a user defined token and
// eventually rate limiting or other restrictions set by the user.
// Options allows the service to authorize to be customized, defaulting to w3s.link.
authorizeContentServeHTTP(restrictions: { token: string }, options: Options): Promise<Result<Delegation>>
// Calls `ucan/revoke` for the given delegation.
// Options allows the service to authorize to be customized, defaulting to w3s.link.
revokeContentServe(delegation: Link, options: Options): Promise<Result<Unit, DelegationNotFound>>
}So, the createSpace function would do what it does currently - delegate space/content/serve/* to enable general access and egress accounting, but for managing tokens you'd use the new methods.
On the server you can then have a KV mapping of spaceDID+token: delegation which you can query to determine if token access is allowed for a space.
| with: SpaceDID, | ||
| nb: Schema.struct({ | ||
| /** The authorization token, if any, used for this request. */ | ||
| token: Schema.string().nullable(), |
There was a problem hiding this comment.
Do we need this defined at this level?
There was a problem hiding this comment.
I agree that defining it at the top level could be overly restrictive. Allowing its use within the transport/http capability seems like a good approach, as it enables revocation without affecting the ability to serve content or record egress. @Peeja, what are your thoughts on this?
| * [IPFS Gateway]: https://specs.ipfs.tech/http-gateways/path-gateway/ | ||
| */ | ||
| export const transportHttp = capability({ | ||
| can: 'space/content/serve/transport/http', |
There was a problem hiding this comment.
IDK if "transport" is useful, makes it very verbose.
Suggestion: space/content/serve/http
There was a problem hiding this comment.
I agree. I'm not sure now who originally proposed transport and why, but I don't think there was strong reasoning that went with it as much as putting something down.
|
Closing this PR for now. Any proposals for handling tokens will be tracked in issue #213. |
Context
We should enable setting a token when delegating the
space/content/serve/*capability. This would allow us to validate thetokenincluded in gateway requests and determine whether to serve the content based on the validation result.Related Issues
space/content/serve/*capability should allowtokenin the caveats project-tracking#213